With introduction of VM (Virtual Machine), its migration to other physical sever in the DC will involve new challenges, such as scattered subnets may cross TORs (Top of Rack) and disjointed address may exist; but the migrated VMs will continue to maintain same IP address.
FIG. 1 is a schematic diagram of a topology of VMs in the prior art. Subnets will be scattered among many Access switches or Top of Rack (TOR) switches within the virtual network. In a very large and highly virtualized data center, there can be hundreds of thousands of VMs, sometimes even millions, due to business demand and highly advanced server virtualization technologies. Because of this ‘ARP table growth’, ‘exponential ARP flooding’ will take place in the Access Network. Managing the disjointed subnet across different TORs needs to be handled.
With introduction of hypervisor with VMs and Network virtualization in the Data Center, the size of MAC table will be very huge. This is the global problem that the Data Center needs to solve.
FIG. 2 is a schematic diagram of a topology of VM Migration in the prior art. For example, please refer to FIG. 2, under the VM migration scenario, ARP broadcast/multicast messages are no longer confined to smaller number of ports, and Access switch/Gateway router needs to flood all the ARP requests on all ports. Because of the VMs movement, VLAN span across multiple racks will force ARP broadcast. Therefore the data center has hundreds of thousands of VMs and thousands of Rack; When the VMs move across Racks, Access Switch MAC table will be very huge. In the flat Layer 2 network, with introduction of VM Migration, Access switch needs to know all the VMs's MAC addresses across all the TORs.
To solve this problem, the prior art provides two solutions, one is that each subnet was assigned to a TOR switch and VM Migration was disallowed, the other is enable Layer 3 capabilities on a TOR, but that causes the high cost and leads to the similar problem in the Layer 3 (L3).
However the applicant found that, there is a clear need for VM Migration in a flat Layer 2 (L2) network within the DC, but the current technology leads to exponential ARP flooding as well increase in MAC table size on the access switch. For example, when the VM is migrated from one TOR to other TOR, the other TOR do not know how to forward the packet of the VM, and Access switch will flood the packet over the whole Layer 2 Network, such that the Access switch may needs to maintain tens of thousands ARP Entries.